\section{Experiments}
\label{exp}
We carried out the following experiments using the implementations.

\subsection{Normal Operation}
\begin{itemize}
\item{Setup} : 
We test the safety conditions of normal operation here. 
The minimum number of servers that can be present in this system is  4. 
This is because to tolerate an adversary that may attack one server during a
share refreshing time window, the minimum servers required is $3n + 1$.
\item{Results} : 
In the case where no server is attacked (where all messages are received by all
$n$ servers correctly, each stage of share refreshing verified successfully.

\end{itemize}
\subsection{Byzantine Server}
A server under attack will show Byzantine behavior. This is where the server
may either drop messages, alter messages or behave correctly. We detect any 
Byzantine servers using a failed signatures (based on the assumption that the 
private keys are not accessible by the adversary).
\subsubsection{Altered Messages}
\begin{itemize}
\item{Setup} :  We set one server out of four to be Byzantine in a $(4,2)$ 
sharing scheme.
\item{Results} : The correct server successfully dropped the messages from 
the byzantine server and we were able to reconstruct the original secret using 
the sub share collections at any combination of 2 correct servers out of the 
3 remaining correct servers. Furthermore this was tested up to 2 levels of share
refreshing by the servers.
\end{itemize}
\subsubsection{Dropped Messages}
\begin{itemize}
\item{Setup} : This experiment allowed us to analyze the correctness of the 
implementation with respect to asynchronous communication. Each server only 
waits for $2t + 1$ servers to communicate with it. Out of these servers there
must be at least $t + 1$ correct servers where they do not send any messages
with incorrect signatures. We tested this making $t$ correct servers 
non responsive and making further $t$ servers display Byzantine behavior where
they alter the message such that signature verification would fail. In this 
experiment $t = 1$ and $n = 4$. Therefore the secret sharing scheme used is 
$(4,2)$.
\item{Results} : Each servers correctly waits for $2t + 1 = 3$ servers to 
participate (including itself) in share refreshing protocol and verifies that it 
has at least $t + 1 = 2$ correct servers out of the 3 before proceeding any 
further. When we increased the number of Byzantine servers to 2, the correct 
servers detected that the system has more than $t = 1$ attacked servers and 
stopped making any progress and exit.
\end{itemize}
\subsection{Dynamic Adversary}
\begin{itemize}
\item{Setup} : A dynamic adversary is able to collect sets of sub shares held by
different servers during different levels of share refreshing. We tested this 
behavior by attempting to reconstruct the secret using such set of share stores
from different servers.
\item{Results} : Share reconstruction fails as expected.
\end{itemize}
\subsection{Performance Tests}

\begin{itemize}
\item{Setup} : We carried out a performance test to demonstrate the exponential blow up of the
number of shares in each round of share refreshing. This was carried out 
with the most simple parameters for the sharing scheme, where $n=3$ and $k=1$, 
where out of the 3 sharings any 2 will be required to reconstruct the main 
secret.

\item{Results} : Table~\ref{table_share_perf} shows the absolute times taken to 
create and reconstruct at each round of share refreshing.
\end{itemize}
\begin{center}
\begin{table}
\caption{Share Refreshing Performance}
\begin{tabular}{| c | p{2.4cm} | p{2.4cm} | p{2.4cm} |}
\hline
  Sharing Iteration & Generation Time ($ms$) & Reconstruction Time ($ms$) & Total Time ($ms$) \\
\hline
\hline
 1 & 11 & 0 & 11 \\
\hline
 2 & 21 & 1 & 22 \\
\hline
 3 & 130 & 6 & 136 \\
\hline
 4 & 793 & 45 & 838 \\
\hline
 5 & 4682 & 152 & 4834 \\
\hline
 6 & 28338 & 246 & 28584 \\
\hline
 7 & 169159 & 1514 & 170673 \\
\hline
\end{tabular}
\label{table_share_perf}
Test machine (xinu01.cs.purdue.edu) configuration :

Processors : Intel(R) Pentium(R) D CPU 3.00GHz (2 processors)

Total memory : 3991084 kB

\end{table}
\end{center}

